-----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+ 8lqrLQ7YpTzyE74pKR1cl5TAUU4= Issuer-Certificate: MIIBkDCCAToCEQCFP7oDPZq0SSDfetbu5nSkMA0GCSqGSIb3DQEBAgUAMEAxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl Y3VyZVdhcmUgUENBMB4XDTk0MDQwNTE3MDQyM1oXDTk1MDQwNTE3MDQyM1owWTEL MAkGA1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMO U2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMFkwCgYEVQgB AQICAgADSwAwSAJBAL4Od/KxhOB6HyUbBJC2X6Ic2P0XEcGnddzJ1QEHjSFyx5qz n098ScMWDEJSiwrsVmQFbNvN01hkke7ZE21aG5sCAwEAATANBgkqhkiG9w0BAQIF AANBAIBzwWRF5SkoGAdcliVyog2caFtsPrq7lyBIp562B+ckFNderoDTc+JW+i4f MhnY9Q9I2KrlZV4GqcpZ+GjAeNk= MIC-Info: RSA-MD5,RSA, A9VvxUJFlZ+UyrP+FQV+UauZKzzjYG0BGEwbe/QKYPiUZm6lRhHMuGIqgSacp1JR tjKiIpYbg/r7pgBXEehhwW0= X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED > > > > > > 1. 25 iterations of DES with the first 8 bytes of the > > > password as key, followed by 25 iterations of DES > > > with the second 8 bytes of password as key. > [ ... better version deleted ... ] > > > (1) can be broken on a workstation with ~ 2^32 steps (and > > > very little in the way of memory); > > > > I've never seen anything resembling a convincing argument for this point. > > > > Hrmm, well, I could give you the crypto explanation...do you > want me to? [Keywords: meet-in-the-middle, birthday attack] .... > > > > SecureWare uses a mechanism similar to this and it is part of one of > > their security offerings. I've used a slightly different, but similar, > > approach for several years > > We do not. See below. > > Good lord! Can anyone give more details? [ The details > tend to matter in this business: something similar but > slightly different might be safe. :-) ] > > Sorry to the rest of you bugtraq folks: I would be taking > this to personal email, except for the fact that someone > actually uses the broken scheme -- yikes! -- that's my ObBug. > This is most certainly NOT SecureWare's password implementation, although I can understand why there might be some confusion. SecureWare has modified the behavior of password hashing not to increase the strength of the underlying crypt(), but to increase the size of the possible password space and the resulting hash value. The algorithm breaks a password into crypt- sized blocks, running crypt() across each block. The salt for each block is derived from the ciphertext of the previous block to provide linkage between the individual blocks. The resulting hash is the concatenation of the various ciphertext blocks, prefixed with the initial salt. This strong mechanism, combined with shadow password files and configurable password controls (random pronounceable password generator, password aging, minimum allowable lengths, attack detection and account lockout, etc...) allow a system security officer to be as paranoid as they choose -- e.g., passwords can be configured to look like standard Unix, they can be configured to be 128 byte random passwords, or they can be configured somewhere in between. As an example, my password is between 8 and 16 bytes long. Its entry in the shadow password database looks like: watt:u_name=watt:u_id#124:\ :u_pwd=8F0Ovkj7jA9jE.ofsJ4MaIt6:\ Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE-----